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ABSTRACT 



A graphics controller ovcriays a movie window over the 
graphics pixel data. Movie pixels arc from a movie source 
and are muxed into the pixel path by a pixel mux near the 
end of the graphics pipeline. A compaiisoo of the current 
pixel count to the pixel address of the start and ending 
boundaries of the movie window controls the pixel mux. 
which selects either graphics pixels or movie pixels for 
display to a screen. Since the graphics controller is 
pipelined, the pixel con^>are near the end of the pipeline 
does not restart the graphics pipeline early enough for it to 
pre-process the graphics pixels. The gr^hics pipeline docs 
not stop during the movie window but instead performs 
dummy fctdies from ttic gr^hics mcmcay to a CRT FIFO 
in the graphics pipeline. Dummy fetches are fetches of 
graphics pixels that are not displayed. Since these fetches 
contain non-displayed pixels, they arc not needed except to 
keep the fetch count counting even during the movie win- 
dow. Other requests are given priority during dummy 
fetches. Thus fetches to fill the CRT FIFO with pixels 
underneath the movie overlay whidi arc not displayed arc 
transparently blocked by activating dummy fctdies. allow- 
ing other requestors to have full access to the graphics 
memory. Dummy fetdics are activated by a compare of the 
fetch counts to the width of the graphics and movie portions 
of the screen, expressed in memory fetches rather than in 
pixels. A comparison of the total fetches in a horizontal line 
to the current fetch count jwevcnts fetching un-displaycd 
pixels past the end of the line. 

24 Claims, 9 Drawing Sheets 
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TRANSPARENT BLOCiONG OF CRT 
REFRESH FETCHES DURING VIDEO 
OVERLAY USING DUMMY FETCHES 

BACKGROUND OF THE INVENTION— FIELD 
OFTHEINVENnON 

Tbis invention relate <i tft yidgp graph ir^ ^<t^m^ and 
more particulariy to overlaying ftiU-motion-vidco frames 
onto a gr^hics screeo. 

BACKGROUND OF THE INVENTION- 
DESCRIPTION OF THE RELATED ART 

Graphics display subsystems have increased in perfor- 
mance and flexibility. The graphics image of the screen is 
built up pixel-by pixel under program control. These pixels 
are often in color, using a red-grecn-blue (RGB) c<dor-space 
coding for the graphics pixels. 

FuU-motion video images may now be partially or fully 
superimposed over the graphics image. Rather than being 
stricdy oomputcT-gencrated. like the graphics data, the video 
overlay, herein referred to as movie overlay, can come from 
a real-time video source such as a televisioo receiver or 
video camera, or perhaps from a video playback device such 
as a CD-ROM. The video overlay image is typically in the 
YUV color-space encoding rather than RGB. Thus the video 
overlay is not directly compatible with the graphics image. 
The video overlay pixels arc normally converted to RGB 
and then muxcd into the pixel stream just before being 
output to the display monitor, 

FIG. I is a diagram of a display, which could be a 
caihode-ray-tube (CRT) video display, or a flat-panel liquid- 
crystal display (LCD) or other type of display. A graphics 
image is farmed on the display screen by selectively ener- 
gizing or illuminating small dots or pixels on the screen. In 
a CRT. a pixel is energized by an electron gun that directs a 
beam of energizing electrons to a particular point on the 
screen. The electron beam is scanned from left to right in a 
horizontal line and pulsed to illuminate some points on the 
line but not others. The screen is divided into a number of 
horizontal lines 19. 12, 16, with each tine comprising a 
nun[ibci of pixels. The pixels in a line are illuminated 
one-by-one from the left side to the right side of a horizontal 
lines 10. 12. 16. 

Once the entire horizontal line 10, 12, 16 has been 
scanned, the electron beam is disabled or '"blanked*" so that 
no pixels are energized and the electron beam is re-traoed 
back to the beginning on the next horizontal line 12. This 
horizontal re-trace 14 follows a diagonal path. After re-trace, 
the blanking is ended and the next horizontal tine 12 is 
scanned. The process of scaiming a horizontal line and 
re-tradng is repealed until all lines are scanned. Once 
scanning of the last horizontal line 16 is complete, die 
electron beam is retiuned to the beginning of the first line 10 
by a vertical retrace 18. The electron beam is again blanked 
to i^event any illumination while the electron beam is being 
retraced to the top of the screen. 

Other display technologies also divide a screen into 
horizontal lines comprised of pixels that are either illumi- 
nated or not A horizontal recovery blanking period 
between horizontal lines and a vertical recovery or blanking 
period to return to the top of the screen may also be 
necessary with these display tedinologics, even though an 
electron beam is not used 

FIG. 2 shows a screen of graj^cs data overlaid with a 
movie window. Each horizontal tine of pixels contains Hn 
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pbtels. VGA 640»t80 resolution has 480 lines of 640 pixels 
per line. Movie window 20 is overiaid on *top* of die 
graphics screen data so that the gr^^hics data underneath 
movie window 20 is not visible. Movie window 20 is also 
5 known as a movie envelope, and the coordinates (in pixels) 
of the upper left ooraer of movie window 20 (Xl.Yi) and die 
lower right caner (X2.Y2) define the size and location 
within the graphics screen. A horizontal scan line 22 which 
passes through movie window 20 has three regions: 

1. 1ST GPX region from pixel 1 to pixel Xl-1 contains 
graphics data: 

2. MOVIE region from pixel XI to pixel X2 contains 
full-modon-vidco data; 

3. 2ND GPX region from pixel X2+1 to end of line, pixel 
Hn, contains graphics data. Only horizontal scan lines 
between lines Yl and Y2 have these three regions and 
reqtiire special processing; other lines contain only 
graphics data and no movie data. 

A pixel mux will select movie overlay pixels during the 
movie window but select graphics ptxek during the first and 

^ second graphics regions, and for lines entirely outside of the 
movie window. This pixel mux is controlled by a simple 
comparison of the current pixel passing through the pixel 
mux with XI and X2. When the pixel is between XI and X2. 
then the movie window is being displayed, and the movie 

25 pixels arc selected. Otherwise the graphics pixels are 
selected. See for example. U.S. Pat. No. 5.404.437. and U.S. 
Pat No. 5.293^40. 

All modem graphics controllers are highly pipelined 
which greatly complicates the muxing of movie or graphics 

30 pixels. F6r example, pixels are normally stored in a laige 
DRAM or VRAM memory, and groups of pixels arc fetched 
and written to a CKT FIFO. The pixels are individually read 
from the CRT FIFO and pass through other stages, such as 
attribute and color mapping before being conv^ed to 
analog voltages by a digital-to-analog converter (DAC). The 
pixel muxing of movie and graphics pixels occiu^ late in this 
pipeline, such as just before die DAC. At the end of Uic 
movie window, as pixel X2 is passing throu^ die pixel mux 
near the DAC. die next pixel must come from the graphics 
path. However, the CRT FIFO is several pipeline stages 
upstream from the pixel mux. The CRT FIFO must be 
re-loaded several clocks before pixel X2 is detected at the 
pixel mux. 

Since die CRT FIFO must be reloaded and re- started for 
the 2ND GPX region several clock cycles before pixel X2 is 

45 detected at the pUel mux, another comparison must be done 
upstream from die pixel mux. Since the CRT FIFO is loaded 
with groups of pixels in each memory fetch, rather than one 
pixel at a time, the compare must be performed on fetches 
rather than pixels. Thus X2 must be reduced by some 

50 number of pixels to allow the CRT FIFO to restart before the 
graphics pixels after pixel X2 arc required. Then the reduced 
X2 must be converted to mcmocy fetches rather than raw 
pixels. 

Graphics controllos may use additional registers to define 
55 fetching for a movie window. A controller may require that 
a CRT FIFO re-start address be programmed into a register. 
The programmer first determines the size of the movie 
window (MVW). then converts pixels to memory fetches, 
and finally half of the width of the movie window is 
60 programmed into the register as an offset address. For 
example, a 320-bit-wide movie window with a color mode 
requiring 4 tnts per pixel, and using a gr£^>hics memory that 
reads 32 hits per fetch reads 32 bits/acccssxpixel/4 bits=8 
pixels/access. The movie window is 320 pixels/(8 pixels/ 
65 access>=40 raemcay accesses wide. Half or 40 accesses is 20 
accesses. The offset address 20 is thus programmed into the 
register. 
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When the suit of the movie window is detected at die 
pixel mux at pixel XI. the CRT FIFO is flushed of aD 
remaining graphics pixels. These flushed pixels are graphics 
pixels for the area underneath the movie window whidi arc 
not displayed. Indeed, these pixels that arc flushed did not 5 
have to be fetched at all. and just waste bandwidth of the 
DRAM grq)hics raemcMy. Once the CRT FIFO is flushed, 
the rc-start offset address from the register is added to the 
CRT FIFO's read counter, and the memory fetches resume 
starting with re-stail address, which is somcv^ere in the lo 
second half of the movie window. Hie CRT FIFO continues 
to fetch pixels from the graphics memory until the CRT 
FIFO becomes fiilL Then pixels are read out of the CRT 
FIFO near the end of the movie window. Some synchroni- 
zation is needed to ensure that the first graphics pixel after i5 
X2 arrives at the pixel mux at the proper time. 

Again, some number of pixels before the end of the movie 
window are fetched into the CRT FIFO brforc the end of the 
movie window. Many of these pixels are not displayed, but 
are underneath the movie window. Thus more un-displayed 20 
pixels are fetched, wasting memory bandwidth. 

FIG. 3 shows that in addition to video boundary registers 
for pixels, a re-start roister is needed to restart a pipelined 
graphics controller at the proper time. An x.y coordinate 
system is used to locate any pixel or boundary on the screen. 25 
Registers 24. 26 contain binary nuraben representing the 
numbers XI and X2. which define the boundaries between 
the video overlay and surrounding graphics regions in a 
horizontal line. Registers 28. 29 contains the line number fcs 
the upper and lower line in the movie window relative to the 30 
graphics lines on the screen. Re-stait register 39 contains an 
ofi'set address within the movie window where the CRT 
FIFO should begin fetching from gr^hics memory. As 
shown on FIG. 2. this rc-start address is in die second half 
of movie window 20. but before the end of movie window 35 
20. This rc-start address allows the gr^)hics pipeline to be 
restarted early so that no g^ occu's at the end of movie 
window 20. 

Another approach is to define a coarse window or enve- 
lope. The coarse window is defined around the tiue movie 40 
window to allow fetching of movie pixels to begin earlier 
than the true movie window. This method defines a coarse 
XI. Yl and X2. Y2 which are compared to the graphics pixel 
count. Thus a pixel-based compare of the coarse window is 
used to start and step fetches early. The approach avoids 45 
fetching unnecessary graphics data and improves the avail- 
able memory bandwidth. 

The (Hior art suffers firom unnecessary fetches from 
graphics memory to fill the ORT FIFO with pixels under- 
neath the movie window that are not displayed. These 50 
unnecessary fetches occur before the CRT FIFO is flushed 
and once it is restarted. FUxther fetching may continue 
beyond the end of the line, and the CRT FIFO is normally 
flushed again at the end of each horizontaJ line, even when 
no movie window is present Again these unnecessary 55 
fetches waste graphics memory bandwidth. This bandwidth 
is critical as gr^hics pixel d^th and refresh rate increase. 
The re-start offset address scheme is complex to understand 
and program and require extra registers and hardware which 
increase silicon area and cost Additionally these registers 60 
may have to be loaded only at specific times, such as during 
vertical retrace, or pipelined to prevent register updates In 
the middle of a line, which could cause tearing of die image 
displayed on the screen. 

What is desired is a pipelined gra{4iics controller that can 65 
efficiently overlay a fuU-motion-video image. It is desired to 
maximize bandwidth available to other devices such as 



writes from the host or a BLT engine or from the movie 
FIFO fill request It is desired to reduce or eliminate unnec- 
essary fetdies of pixels that arc not displayed on the screen, 
but are underneath the movie window or beyond the end of 
the line. It is also desired to eliminate extra registers to save 
die area and cost It is desired to achieve these goals in a 
manner transparent to software. 

SUMMARY OF THE INVENTION 

A pipelined graphics controller overlays a movie windo w 
over a yaptiics screen. The pipelined graphics controller h as 
a |Hxel mux which selects graphics pixeb or movie plxeiJ?or 
' on a screen. A LJRT FIFO receives teicnes of 




gr^hics pixels from a graphics memory and siq^plies gr^- 
ics pixels to the pixd mux. A pixel counter counts a number 
of pixels processed for display on the saeen in a current 
horizontal line and outputs a current pixel count. A pixel 
compare means receives the current pixel count and a 
starting pixel address and an ending pixel address of the 
movie window on the screen. It signals to the pixel mux 
when to select movie pixels and when to select graphics 
pixels fcr display o n the screen. 

A It^UJh counter counts a number of fetches of graphics 
pixels from the graphics memory to the CRT FIFO. The 
fetch counter counts true fetches wherein graphics pixels are 
physically written to the CRT FIFO and counts dummy 
fetches wherein no graphics pixels are physically written to 
the CRT FIFO. The fetch counter ou^uts a cmrcni fetch 
count. A first fetch compare means receives the current fetch 
count and receives the starting pixel address of die movie 
window converted to fetches. It indicates after a first match 
is detected that dummy fetches to the CRT FIFO can now be 
performed radier than only true fetches. 

Dummy fetches to the CRT FIFO arc performed during 
the movie window. No graphics pixels are physically fetched 
from the graphics memory to the CRT FIFO during the 
dunmiy fetches. The entire graphics controller is fooled into 
thinking that actual CRT fetches are occurring. 

In further aspects of the invention a movie FIFO receives 
movie pixels. The movie FIFO supplies movie pixels to the 
pixel mux. A video f etdi compare means receives the cuirent 
fetch count and receives the ending pixel address of the 
movie window converted to fetches. It indicates after a 
movie-end match is detected that dummy fetches to the CRT 
FIFO can no longer be performed. Thus the end to the 
dummy fetches is signaled when die movic-end match is 
detected between the current fetdt count and the ending 
pixel address of the movie window converted to fetches. 

In some aspects another requestor is a request to write 
movie pixels to the movie FIFO. Non-displayed graphics 
pixels are fetched after the first match and before the 
movie-end match. The non-displayed pixels are not dis- 
played on the screen but the movie pixels are displayed on 
the screen in place of the non-displayed graphics pixels. 

Other aspects of the invention include a write counter for 
the CRT FEPO. The write counter indicates a location within 
the CRT FIFO to write graphics pixels fetched from the 
graphics memory and is incremented for true fetches and for 
dummy fetches. Thus the write counter is also incremented 
for dummy fetches when no gr^hics pixels are written into 
the CRT FIFO, A read counter for die CRT FIFO indicates 
a location within the CRT FIFO to read graphics pixels for 
transfer to the pixel mux. The read counter is continuously 
incremented by read requests during a current horizontal line 
induding when the movie {uxels arc selected by the pixd 
mux. 
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BRIEF DESCRIFnON OF THE DRAWINGS 

FIG. 1 is a diagram of a display, which could be a 
cathode-ray-tubc (CRT) video display, or a flat-panel liquid- 
crystal display (LCD) or other tyjic of display. ^ 

FIG. 2 shows a screen of gr^hics data ovcriaid with a 
movie wbdow. 

FIG. 3 shows that in addition to video boundary registers 
for pixels, a re-start register is needed to restart a pipelined 
gr^^hics controller at the proper time. lO 

FIG. 4 shows a cathode-ray-tube (CRT) controller sub- 
system with graphics and video overlay. 

FIG. 5A shows the pixel addresses being compared for 
control of the pixel mux. 

FIG. 5B shows the line numbers being compared for 
control of the pixel mux. 

FIG. 6 shows conq>ansons of the fetch counts from 
graphics or movie memories to the graphics fetch counter. 

FIG. 7 shows the arbitration for the graphics memory diat 20 
favors external sources during dummy^CRT cycles which 
occur during the movie window. 

FIG. 8 shows die CRT FIFO read and write pointers that 
are incremented even during dunmiy cycles. 

FIG. 9 shows a block dia^mi of a video sub-system ^ 
driving a CRT and an LCD. 

FIG. 10 shows a screen with a video overlay window and 
the fetch counts that arc programmed into registers. 

DETAILED DESCRIFnON ^ 

The present invention relates to an im^irovement in graph- 
ics controllers. The following description is presented to 
enable one of ordinary skill in the ait to make and use the 
invention as provided in the context of a particular applica- 3S 
tion and its requirements. Various modifications to the 
preferred embodiment will be apparent to those with skill in 
the art. and the general principles defined herein nuy be 
applied to otha embodiments. Therefore, die jycsent inven- 
tion is not intended to be limited to the particular embodi- 40 
ments shown and described, but is to be accorded the widest 
scope consistent with the principles and novel features 
herein disclosed. 

A PIPELINED VIDEO SUB-SYSTBM— FIG. 4 

FIG. 4 shows a catfiode-ray-tube (CRT) controller sub- 45 
system with gr^hics and movie overlay. A host S$ such as 
a personal computer processor updates information to be 
displayed on CRT monitor 62. The update infoimation is 
written to a host buffer 52 synchronized to a host bus clock. 
Memoty controller 54 receives a request from host buffer 52 so 
when update infcnnation has been wriaen by the host 
Memory controller 54 transfers the iq>diate information from 
host buffer 52 to graphics memory 56 once the request from 
the host buffer is granted priority from arbitration with other 
requesters. An arbitration unit inside the memory controller 52 
arbitrates between several requesters desiring access to the 
graphics memory 56. These requesters produce host 
requests, display refresh requests, and dynamic-RAM 
refresh requests to refresh the dynamic memory chips in 
gr^hics memory 56. Other requestors include a half-firamc 60 
buffer, a bit-block transfer (BLT), a GUI accelerator request 
hardware cursor, icon support logic, external zoom-video 
(zv). 

Pixel Data Path to Screen 

' llie CRT monit(y 62~must be continuously u pdated or 65 
refreshed ^ 9 ***** rtispiay ir^i gymauon sto red in the 
gr^hics memory 56 may be visible. ITius a steady^aream ot. 
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display data must be transferred to the CRT from the 
gaphicTmemory 56. which contains a complet e "snapshot" 
of mc tnfonnaUon to display. A LkI' hl^O 58 irprgv iaa to 
butter me data mat is tra as t erred by mcmnry controDcr. The 
data buffered b y OgT FIFO 58 is docked out to attribute 
coTtgoUer 61, which may ^^difa^gie^pix el data, perhaps by 
re-mapping the colors r^esentedor iHIhking the pixels. 
Some mode s hypagg attrihutft controller 61. 
The modified pixel data is clocked out of attribute cod- 
troiler 61 to RAM 60 by a video clock. RAM 60 contains a 
RAM that is indexed by the pixel data, and outputs digital 
values for red. green, and blue sub-pixds that con:^)rise a 
color pixel. Pixel data leaves RAM 60 and is passed through 
pixel mux 32 to DAC 65. DAC 65 contains a digital-to- 
analog convener (DAQ that converts the digital color 
sub-pixels to analog intensity values that are transmitted to 
the CRT monitor 62. Eidier RGB graphics pixels may be 
converted to analog values by appropriate programming of 
translation values into RAM 60. 

Movie overlay data in YUV format Is loaded into movie 
FIFO 30. and then docked to scaler 63 which performs 
scaling and color-space conversion. Pixel mux 32 then 
selects either movie overlay data from the movie path or 
gr^hics pixds from attribute controDcr 61. DAC 65 con- 
verts the data into analog format for display by CRT monitor 
62. 

TWO LEVELS OF COMPARES— PIXELS AND 
FFTCHES 

The current pixel being jwocesscd must be compared to 
the boundaries of the movie window to determine when 
movie pixels rather than graphics pixels should be sent to the 
screen. T\vo different types or levels of con^ares are per- 
formed to determine when the movie window is active for 
different stages in the pipeline. The primary compare is a 
pixel-address oonc^arc before the pixel mux. to sdect either 
the pixel stream from the graphics controller or from the 
movie controller. 

Because the graphics and movie paths are pipelined, 
second compares are also performed at an upstream stage. 
Near the movie FIFO the width of the movie window is 
con4)ared to die current count of fetches from movie 
memory. Also the width of the first graphics region before 
the movie window is compared to the current fetdi count for 
loading the CRT FIFO, and finally this current fetch count is 
con^iared to the total width of the line. 

For these second compares, fetches are the unit of 
comparisoo. rather than individual pixels. Fetches typically 
contain several pixeb. depending on color depth. For a 
128-bit memOTy fetch. l6-bits per pixel will result in 128 
bits/16 bits/pixel=8 pixds per fetch, but 4-bits per pixel 
results in 128 bits/4 bits^ixel=32 pixels per fetch. The 
counters in the memory controller keep track of die current 
fetch count 

PIXEL COMPARES NEAR PIXEL MUX 

FIG, 5A shows the pixel addresses being compared for 
control of the pixel mux. The cocM'dinates XI and X2 define 
the beginning and end of the movie window for a horizontal 
line that indudes a portion of the movie window. A com- 
parison of the current line number to the line numbers for the 
top and bottom lines of the movie window determine if the 
current horizontal line indudes a portion of the movie 
window, A count of the cucrcnt pixd being processed is kept 
using register 38 and incremcnter 40. Tlie current pixd 
count can keep track <^ the current pixel count for a pixel in 
any stage of the graphics pipeline, but preferably it keeps 
track of the pixels one stage before ^e pixel mux. to allow 
time to switch the mux when a match occurs. Altematdy the 
comparator output itself may be pipelined using well-known 
techniques. t 
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Rcgi^cr 38 is Initialized to zero by mux 42 during the upper grs^hics region, above movie window 20 of FIGS. 2. 

horizontal retrace period, before a new line begins to be and 10. SR ftq>-flop 144 is set by this detected matdi from 

written to the screen. The signal HTNTT is active then, and conq)arator 146. The movic-Une signal is driven high to 

may be a derivative to the horizontal sync or hcnzontal indicate that the lines now include pixels which come from 

blanking signal. After initializatioa. as each pixel is written 3 the movie FIFO rather than the ORT FIFO, 

to the new Unc on the screen, incremcnter 40 adds one to the As lines containing movie pixels are written to the saccn 

current pixel count in register 38 and writes the incremented during the movie window, the lower boundary of the movie 

count back to register 38. Thus register 38 contains die window, Y2 from register 29, is compared to the current line 

cuirent pixel count for the line being drawn to the screen. count from register 138. Y2 is larger ttian Yl when the 

This current pixel count is conqsared by cortqiarator 46 to lO movie window is present When comparator 147 detects a 

the left boundary of the movie window. XI, which is stored match at the lower line of the movie window. SR flip-flop 

in register 24. When the current pixel count matches XI. the 144 is cleared and the movie-line signal is driven low, 

pixel being drawn to die screen is the last pixel in the first causing the pixel mux to only select gr^hics pixels again, 

graphics region. 1ST GPX of FIGS. 2, and 10. SR flip-flop The region below movie window 20 on FIGS. 2. 10 is then 

44 is set by this detected match frt>m comparator 46. AND 15 entmd. line widi only gr^>hics pixels are written to the 

gate 116 ensures that the current horizontal line is within die screen until die cuircDt line pixel count from register 138 

movie window using die logic of FIG. 5B. The movie- matches die total number of line on the screen. Vn from 

envelcpe signal is driven high to indicate that the pixels now register 136. When comparator 149 detects the match at the 

come from the movie FIFO rather than the CKF FIFO. The end of die screen, an end-of-screen signal is activated and a 

movie envelope signal is the select signal for the pixel mux. 20 new votical re-trace period begins. 

As movie pixels arc written to die screen during die mov ie FETCH COMPARES NEAR FIFOS— HG. 6 

" window, tihe second region o f FlUS. 2. lU. the secon d FIG. 6 shows comparisons of the fetch counts from 

SbundarV^f BiTlnd ^e window. X2 from register 267 is gr^hics memory to the graphics fetch counler. The comr 

c ompared toTHc'current TOxel count from register 38. X2 is parisons of FIG. 6 arc performed upstream in the pipelines 

lar gCT than XI when the movie window is! present W hen 25 relative to the pixel mux and the pixel comparisons 

co mparator 47 de tec t a match at the end of the mov ie described for FIG. 5. 

mndow. iik hip-SS^^ is cleared and the movie-eqvelo pe The number of fetches from graphics memory is stored in 

s ippkl is dnyf n l ^'^ r3m Ain g_the pixel mux to n ow select register 96 as the current fetch count Inaementcr 100 

graphics pixels again. The third region, labeled 2ND GFX increments die current fetch count each time a fetch from 

on HGS. 2. 10. is then entered. Grqjhics pixels are then 30 graphics memory occurs. Each fetch may contain several 

written to the screen until the current pixel count from pixels. Mux 98 initializes register 96 before the beginning of 

register 38 matches die total length in pixels erf the line. Hn a new line, such as during the horizontal sync or retrace 

from register 36. When comparator 49 detects the match at period. 

die end of die line, an end-of-line signal Is activated, halting ,Each fetch may contain several graphics pixels in RGB 

the writing of moie pixels to the screen past the end of the 35 format or movie pixels in YUV formal such as 4-2-2 or 4-4-4 

visible line. for Y-U-V. During initialization of new line, before the 

'■ — iTie comparisons of FIG. 5 are all conq>arisons based on beginning of the movie window, the CRT and movie FIFO's 

die number of pixels until address XI, X2. or the whole line. arc loaded during the retrace period. As pixels arc read out 

The current pixel count from register 38 continues to count of diese FIFO's, a write request is generated to the mcmcffy 

during the movie window and is not reset at the end of the 40 controller to write more pixels from the graphics memory to 

movie window. It is only reset at the end of the line. these FIFO's. This write request may be generated before 

Comparators 46. 47. 49 and registers 24, 26, 38 need to be the FIFO becomes empty, such as when 2 or more rows in 

large enough for the largest line supported. For standard the FIFO are empty. 

VGA. this is 640 pixels. The three con^>arators can actually Movie bitsfaixcls is preferably die s a me sizc ^ s graphics 

use the same physical hardware as explained later. 43 bi dr/pixels. although In the Vuv tormatTnius the number ot 

FIG. 5B shows the line-comparators for determining ' movie pixels writ ten to th e screen will be the same as the 

when a current horizontal line falls within the movie enve- nuiCPg^f "grapmcTplXBlji th ai are hid d en. 11 the 0^r~m d 

lope. The line numbers or coordinates Yl and Y2 define die i novie MMI's are doi^ffu5ed Wtth same-sizea data pa dis. 

first and last line of die movie window. A conq>arison of the tBen the numb er of movie fetches equals the niimt>CT of 

current line nunabcr of the current line to die line numbers 50 gra phics leicnes ov CT iaid Thus a single fetch counter m ay 

for the top and bottom lines of the movie window determine beusco. ' ~ ~ X^L^K^ 

if die current hwizontai line includes a portion of die movie " Register 82 is loA4ed widi die n"m^ fe tohes from >^ ^ 

window. A count of die current Une being jffooessed is kept gr^Jiics memory needed to fetch aU the graphics pixels 

using register 138 and incrementer 140. d imng the first graphics region. 1 ST GPX. Register 88 is 

Register 138 is initialized to zero by mux 142 during the 55 loaded wife the, nun^ of fetchb^ nee ded to fetdi all di e 

vertical retrace period, before a new screen begins to be p ixels fg a lull Une. Both registCTs 82, irit are loaoeaw idi 

written to the screen. The signal YXNTT is active then, and t hynumber of fetches, which is a numbgr of pixels divide d 

may be a derivative to the vertical sync or vertical blanking b y^ the' number of pixels retrieved in eacii memory acce ss, 

signal After initialization, as each line is written to die TTi e result is rounded up if necessary to ensure diat all pixe ls 

screen, incrementer 140 adds one to the current Une count in 60 are retrieved. Shifter hardware calculates the number of 

register 138 and writes die incremented count back to fetches from die number of pixels and fee graphics mode for 

register 138. Thus register 138 contains fee cuirent line loading into registers 82, 88. which vary for different reso- 

number for fee line being drawn to fee screen. lutlons an color dcpfes. The value in register 82 also varies 

This current line count is compared by con^arator 146 to wife fee placement on Thf ';m:rn nf thr m^fvi* ^^inflnw 

fee upper lx)undary of fee movie window, Yl, which is 65 Raster 86 is loaded wife fee sum of fee width of fee 

stored in register 2i8. When fee current line count matches movie window and the first graphics region, 1ST GPX. 

Yl. fee Une being drawn to fee screen is fee last line in fee expressed in fetches. 
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OperatioD of Fetch Counters and Conq>aratQrs 

At the begiiiniag of a new horizontal line, register 96 is 
cleared. As the CRT FIFO is loaded from the graphics 
memory, each f^ch cycle increments the current fetch count 
in register 96. The current fetch count is compared by 
conqjarator 90 to the width of the first graphics region, 1ST 
GPX of FIG. 10, and when a match occurs SR flip-flip 84 is 
set activating the dummy^CKI signal through AND gate 
117 when a vertical line match is also detected by the line 
comparator of FIG. SB. At this point, enough pixels have 
been fetched into the ORT FIFO to reach pixel XI, the last 
graphics pixel before the movie window. 

Movie fetches occur during the horizontal retrace period 
to fill the movie FIFO. Once the movie FIFO is full, these 
fetches stop until some movie pixels are read out of the 
movie FIFO. The current count in register 96 is incremented 
for each dummy CRT fetch, which can occur at the same 
time as these movie fetches. As the movie window starts 
after pixel XI, the fetch count continues to increment from 
dummy CRT fetches until the full width of movie pixels 
have been loaded into the movie FIFO. At this point a match 
is signaled by comparator 92 between the current fetdi count 
from register 96 and the width of the movie window and ISTT 
GPX region in register 86. This match indicates that graph- 
ics pixels should now be fetched for the second graphics 
region. 2ND GPX. The last few movie pixels continue to be 
written to the screen through the various pipeline stages. 
Especially when the nravie FIFO is large, the match from 
oonoparator 92 is signaled many cycles before the last movie 
pixel is drawn to the screen. 

The match from comparator 92 resets SR fli|>-flop 84. 
turning off the dummy_CRr signal. This dummy_CRr 
signal indicates when dummy fetches to the CRT FIFO are 
performed. Dummy fetches arc fetches corresponding to 
graphics pixels that are not displayed. Since these fetch 
contain non-displayed pixels, they arc not needed except to 
keep the fetch count in register 96 counting even during the 
movie window and to update the CRT FIFO*s read and write 

pointers. Other arbiters are given priority during dummy 

CRT cycles as explained for FIG. 7. 

Finally as regular, non-dummy _CRr graphics fetches 
continue after the movie-end match is signaled by compara- 
tor 92. the total graphics fetches in the hOTizontai line, stored 
in register 88, is compared by comparator 94 to the current 
fetch coimt from register 96. A matdi signals that all the 
pixels in the horizontal line have been fetched from graphics 
memory, though they have not all yet been written to the 
screen. The end-of-line-fetches signal from cono^arator 94 
causes gr^hics fetching to cease for this line. Thus unused 
jaxth past the end of the line are not fetched, reducing the 
bandwidth used by fetches to the CRT FIFO. 
HOST WINS ARBITRATION DURING DUMMY 
CYCLES— FIG. 7 

FIG. 7 shows the arbitration for the graphics memory that 
favors souQres other than CRT screen refresh during 
dummy_CRr cycles u^ch occur during the movie window. 
Arbitration logic selects one of the requesting sources as toe 
winner and outputs this cycle type as CYC_jrYPE. 
Normally, requests fen* filling the CRT FIFO using graphics 
memory fetches has a very high priority, since not perform- 
ing these fetches could result in pixels not being wriUen to 
the screen at the proper time. However, during dummy_ 
CRT cycles when the movie window is active, the graphics 
pixels arc not really needed. So the other arbitration sources 
win the arbitration over dummy cycles, but dummy CRT 
cycles are issued in parallel. If there arc no other requesters 
other than dummy fetch cycles, then dicsc dummy fetch 
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cycles still occuz. However, when the host, BLT engine, or 
DRAM refresh request access of the graphics memory when 
the dununy_CRr signal is active, then these otho" request- 
ers win the arbitration along with dummy CRT cycles. 

s Read and write control signals are generated by memory 
controller 54 for both the movie and CRT FIFO. Dunmjy 
CRT cycles activate the CRT FIFO read and write request 
signals to keep inaementing the CRT FIFO and to continue 
to shift non-displayed pixels out of the CRT FIFO. 

10 GRAPHICS COUNTERS STILL INCREMENTED FOR 
DUMMY CYCLES DURING MOVIE WINDOW 

The counters for the CRT FIFO are still incremented for 
dummy cycles. Thus when a host cycle is using the graph ics 
ji ignory ana no pixel data is actually tctched to theCRT 

15 FIFO, ttit UKJ t*wu still incremenu its rounters as k a E ue 
f etch had occurred, even though invalid pixel dati^ as 
v^ ntten in. Si nce the pixel data during du mmy cycles are no t 
d isplayea put coverea by the movie wmaow. the actual da ta 
i s'SoTrelevanL Since me retcn counters or Flu. 6 are a lso 

20 incre mented for each fetch, includin g dumm y Tetches. these 
counters are usea to count me fetches to the end of the 
horizontal line. Just as if no full-motion video were dis- 
played. The graphics pixels in the CRT FIFO can also 
continue to be read and passed down the gr^hics pipeline. 

25 but are blocked at the pixel mux where they are simply 
overwriaen by the next pixel until the mux switches to 
graphics pixels when the X2 pixel match is signaled. Thus 
the graphics pixels are always ready fcr an immediate pixel 
mux switch with no delay to re-start the graphics pixel 

30 pipeline. 

—FIG. 8 shows tfie CRT FIFO read and write pointers that 
are incremented even during dummy cycles. Pixel mux 32 
selects movie pixels from the movie path when its select 
signal, movie envelope from RG. 5, is active. Pixel mux 32 

35 selects graphics pixels from the CRT path when movie 
envelope is inactive. The movie read request signal MVE_ 
RD_REQ from memory controller 54 is sent to movie FIFO 
30 to clock pixels out during the movie window but not 
otherwise. This keeps the movie FIFO from losing pixel data 

40 before or after the movie window. Read counter and decoder 
58R of CRT FIFO 58 receives Ae CRT read request signal 
CRT _RD _jyEQ from memory controller 54 to clock pixels 
out of the CRT FIFO, even during dummy cydes. The 
background pixels during dummy cycles are not displayed 

45 but are covered up by the movie overlay. 

Movie FIFO 30 receives movie pixels from movie overlay 
memory 114. which may not be a real memory at all, but can 
be an active video source such as a TV scan or a video 
camera output stream that is properly synchronized. Movie 

50 ovCTlay memory 114 may aJso l>e from the same DRAM or 
VRAM memory ch ip also used for graphics memory 56. 
^ Graphics pixels ^are read from graphics memcay 56 and 
written to CRT FIFO 58 during CRT fetches. During dummy 
fetches pixel data is not read from graphics memc^ 56 since 

55 gr^hics memory 56 is in use by another requestor such as 
the host or movie FIFO 30 when movie overlay memory 114 
shares the same memcny chip as graphics memory 56. 
However, write counter and decoder 58W is stiU incre- 
mented for all dummy cycles, since the CRT write request 

60 signal CRr_WR^J^Q from memory controller 54 is gen- 
erated when another request a* wins arbitration and executes 
a cycle when dummy_CRr is active. Normal CRT FIFO 
fills activate CRr_WILJ^Q which also increments write 
counter and decoder 58W. As pixels are shifted out of CRT 

65 FIFO 58, even during dummy CRT cycles. CRr_WR_ 
REQ and CRr_JU)_REQ continue to be generated for 
dummy cydes during the move envelope. 
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Addidooal pipelice stages 55 arc present between movie Movie overlay manory 34 can be consmicted from the 
FIFO 30 and pixel mux 32. and between CRT. FIFO 58 and same memory ch^s as gr^hics memory 56. Memory con- 
pixel mux 32. Pipeline stages 55 may include an attribute troUer 54 can then transfer movie pixels from movie overlay 
controller, color-space converter or other logic. memory 34 to movie FIFO 30 without the need of a separate 
iXlD AND CRT CONTROLLER-^G. 9 3 movie controUex. 

no. 9 shows a block diagram of a video sub-system Programming Registers for Movie Overiay Operation 

driving a CRT and an LCD. Ahosi bus such as a PQ bus 53 fiQ jq shows a screen with a movie overlay window 2# 

on the host transfers data to and from memory controller 54 (hat are loaded into registers by shifting 

widi me aid of host bus-intcrfeoe unit 51. PQ bus 53 is an shifting logic can be constructed from barrel 

industry-standard intafacc bus defined by a consortium of ^j^^ ^ ^j^^^ pafoim a binary divide operation, 

personal computer m^ufacturers. , ^ , . For example, a shift by three binary bU-positions performs 

Memory controUer 54 uses memory dock to transfe host ^ ^ deterrnined^ the color depth 

data. Graphics '6 may r«^^^^ (size of ead, pixel) and the width of the ^hics mem^ 
to prevent data loss from leakage m the dynamic memory 1^ . Y^r> r 1 j j *t ^^-^ \ ^ 
d^s in graphics memory sTSlock transfcns and manipu- » J of HG. 6 is loaded by &c shifting logic widi fee 
lation of the video data in gra^iics memory 56 may be 13 nurnba of graj^ memory fetches needed to read the 
accompUshed by BLT engine 7Z which itself operates using Pi^^cls from the start of the hwizontal Unc until the beginning 
the memory dock- A hardware cursor and icon-drawing of the movie window 20. This is the first graf^cs region 
logic is provided by HWC logic 74. Memory controUer 54 labeled 1ST GPX. Register 88 is loaded with the total 
transfers video data to and from HWC logic 74 and graphics number of graphics fetches to retrieve all the pixds in any 
memory 56. 20 horizontal line, including those lines outside of movie win- 
Memory controller 54 also writes pixel data from graphics dow 20. This register is thus loaded with Hn pixels divided 
memory 56 to CRT FIFO 58 for refreshing CRT monitor 62 by the number of pixels per fetch. Register 86 is loaded with 
and/or LCD screen 80. Data may also be written to half- the movie window and first graphics window widths in 
frame buffer 76. which buffers half of the saecn when a fetches. X2(FETCHES). This is simply the value X2 con- 
dual-scan LCD screen is used. 25 verted to fetches. 

Pixel data is transferred from CRT FIFO 58 to attribute As a horizontal line is scanned from left to right and pixels 
controller 61 using the video clock. Attribute controller 61 are drawn to the screen, register 96 keeps incrementing to 
may re-map or alter the color represented by the pixel data keep track of the total number of fetches from gr^ihics 
by using a color look-up table. Other attributes, such as memory, including dummy fctdies. 
blinking or reverse-video characters may be applied by 30 The pixel addresses XI and X2 must also be stored in 
attribute controller 61. registers for the pixel compare of FIG. 5. which controls the 
RAM 60 receives the modified pixd data from attribute pixel mux at the end of the pipeline. These pixels addresses 
controller 61. RAM 60 contains a RAM that is indexed by XI, X2 are converted to fetches by the shifting logic and 
the pixel data, and ou^uts digital values for red, green, and then the result loaded into the fetch registers. The fetch 
blue sub-pixels that con^se a color pixd. Pixel mux 32 35 registers are preferably re-loaded during each vertical blank- 
selects graphics pixels from RAM 60 or scaled movie pixels ing period for the next screen. Thus an offset or re-start 
from scaler 63 for output to DAC 65. DAC 65 contains a address does not have to be stored, 
digital-to-analog converter (DAC) that converts the digital ADVANTAGES OF THE INVE>mON 
color sub-pixels to analog intensity values that arc transmit- The bandwidth used fw refreshing the CRT FIFO is 
ted to the CRT monitor 62. The video clock is used to create 40 reduced by not fetching un-displayed pixels during dummy 
the analog ou^ut to CRT monitor 62 by timing the transfer cycles when another requester arbitrates for the graphics 
of the analog pixel intensity data outputted. memory. Since the other requesters always win arbitration 
Digital pixel data from pixd mux 32 is clocked to over CRT FIFO fill requests during dummy cycles when the 
Gray-scale controller 78 by panel clock PCLK. The digital pixels fetched would not be displayed anyway, the latency 
pixel data is taken from pixel mux 32 after RAM 60 has been 43 for these requestors is also reduced. Power can also be 
accessed and has output the digital sub-pixels, but before reduced since additional pixels during the movie window 
conversion to analog values by DAC 65. Gray-scale con- and beyond the end of the horizontal line are not fetched. 
troUer 78 may perform a gray-scale conversion of the color Both bandwidth and power consumption are kept at thcb 
sub-pixels if LCD screen 80 is monochrome or color, or may minimum since exactly the number of pixels required for 
perform some other conversion or dithering of the pixel data 50 display are fetched and no more. Dummy fetches are fetches 
to a format accepted by LCD screen 80, The converted pixel of graphics pixels that are not displayed. Since these fetch 
data from Gray-scale controller 78 is clocked into the LCD contain non-displayed pixels, they are not needed except to 
screen 80 using the direct panel clock, PCLK^*. LCD saeen keep the fetch count in register 96 counting even during the 
80 may itself include some additional control or conversion movie window. The CRT FIFO request is taken out of 
logic to manipulate the pixel data before its is visually 55 arbitration and other requesters are given P^^^ during 
displayed on a screen, and it may be of many different types dummy^CRT cycles. Thus fetches to fill the CRT FIFO with 
or technologies. When the LCD screen is of the dual-panel pixels underneath the video overlay which arc not displayed 
type, pixel data is also supplied by an indirect path from are transparently blocked by activating the dummy _CRr 
half-frame buffer 76, being clocked in by indirect panel signal, allowing other requesters to have full access to the 
clock PCLK.. M graphics memory. 

Movie data in YUV format is loaded from movie overlay ALTERNATE EMBODIMENTS 

memory 34 into movie FIFO 30, and then clocked by tfic Several other embodiments are contemplated by the 

movie clock to color-space converter and scalo- 63 and then inventor. For example the various blocks of the video 

to pixel mux 32. which selects either movie overlay data sub-system may be integrated onto one ca- more silicon 

from movie FIFO 30 and scaler 63 or graphics pixels from 65 substrates, depending upon the technology used. The inven- 

attribute controller 61 and RAM 60. DAC 65 then converts tion has been descrit>cd in terms of a combined CRT and 

the YUV pixels into analog voltages. LCD controller, but the invention could apply to desktop 
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con^uters with only CRT that arc designed to be energy- first fetch compare means» receiving the current fetch 

effidcnl. The inventioD could also be used for LCD-only count and receiving ihe starting pixel address of the 

systems. A full-frame buffa may be used rather than a movie window converted to fetches, for indicating after 

half-frame buffer, and the gray-scale controller may be a first match is detected that dummy fetches to the CRT 

deleted so that the graphics controUcr drives the LCD screen 5 can now be performed rather than only true 

directly. This is often true for thin-film-transistor (TFT) ^ fet<*cs; ^^—^ „.^,. 

disolav sCTCcns. whereby dummy fetches to the CRT FIFO are performed for 

^ ^ . . ^. , „ the movie window, wherein no graphics pixels are physi- 

Thc movie wmdow, sometimes known as full-motion „ , . . , ^^LZ^, L nirr mn 

video, may actuaUy be a relatively static image such as f"/ ^T^^' "^"""^ ^ 

images from a sUde show. However, the pixel data for the lO dunngthe dummy fetd«s. 

: 7^ . . - * ^ or-D r . 2- The pipelined gr^ihics controller of claim 1 whcrcm 

movie wmdow is in YUV format rather than RGB fonnat as . _ zIJJZ^^a tu^ ^^,.».t»^ orv; 

. ^ _^ J . , ^ ^ T>^T» w •*! dummy fetches are performed when another requester arbi- 

isthusstoredseparatelyfromtheRGBgrap^csd^athcr ^^^^^ ^ the graphics memory after Z first fetch 

in a separate memory, or m a separate part of die frame detecte ti^e first match. 

buffer memory. Two or more movie wmdows may be w"**'"^ ^^i^ uj, ^ , . * u • 

, ^ * *" . . . , . . , „ 3. The pipelined graphics controller of claim 2 whcrcm 

seoarately overlaid onto the graphics data by additional 15 * |^4^«*" &^-t~* . r_ ■ ^ c 

»^i«iiuw7 V wx«« vutv w i vrnf anothcT requesiCT IS Selected from the gTOup cousisting of a 

lOQc. or preferably re-use of the existme loeic. The YUV »—^~» i ^ «. _* 

lu^u. w picicicujiy ic-u*c «i ui* Ai s 6 requesting to write to die graphics memory, a host 

movie data may also be stored as part of the graphics data. * ^ ^ ^ L -Dt •t**-™ 

J ^ J 1. . I . t^,. requesting to read from the graphics memory, a BLT transfer 

The compares described herein may also be pipehned to t.^- ^ j . i-j 

detenni^Iitches a cycle or two befL actioB ^required « ff-fr*""' t'-f^^ «° ""^^ "'^ 

Rip-flop storage elements nwy be add«J to ^^^^^ 20 P°4;j2e^lined graphics controUer of claim I fuithcx 

the pipelines. The pixel addresses XI and Xz can be . . '7^ ^ *^ 

convened to fetches by the programmer, or In software or con^mg. ,..^„,„{„„ 

conversion logic may be addedlo the controUer. » «»«>^« ^^DO. rece.vmg movie pixels, for supplying 

The eomparaors described herein are preferably com- "o^'e P««»s «<> P««» . ^ 

bined into a single fetch comparator and a single pixel 2S video fetch compare means, teceivmg the currem fetch 

comparator. The three registers are simply muxed to the count and receiving the ending pixel address of toe 

single comparator during each of the three regions, and a movie window converted to fetches, for indicating after 

transition to another region, signaled by a match, simply a movie-end match is detected that dummy fetches to 

changes (he mux controls to select the next register. Une the CRT FIFO can no longer be performed rather than 

compares may be perfoimed to either include or exclude the 30 only true fetches; . , ^ ^ 

top and bottom Unes of the movie window. whereby die end to the dummy fetches is signaled when the 

Another altcmaie embodiment is to use pixel countm that movie-end match is detected between the current fetch count 

arc character counters. A chaiacta is typically 8 pixels, so a *e ending pixel address of die movie window converted 

character counter is simply a divided-down pixel counter. to fetches. ^ , . . ^ . 

The foregoing description of the embodiments of the 3S «• "Hie pipelined graphics controUer of daun 4 wherein 

invention has been presented for die puiposes of iUustration anoth» requestor is a request to write nwvie pixels to die 

and desCTipdon. It is not intended to be exhaustive or to limit movie FIFO. .. ^ , , ^ ^ . 

the invention to die precise form disclosed. Many modifl- «• "Hie pipelined graphics controUer of daiin 4 wherem 

cations and variations ant possible in light of (he above movie 'etdies comprise a same number of movie pae^ 

teaching. It is intended that die scope of the invention be 40 » of graphics pixels in cadi tnie fetch to die CRT 

Umited not by tiiis detaUed descriptiOD. but rather by die PJFO. ... . . ...... ^ ■ 

daims appended hereto. pipelined g«P^cs controUer of daun 4 wbaein 

I claim* non-displayed graphics pixels fetched after the first match 

L A pipelined graphics contioUer for overlaying a movie and before the moyie^cnd match are not displayed on the 

window over a graphics saeen, the pipelined gra^rfiics 45 screen but movie pixels arc displayed on the screen m place 

controUer comprising: of the non-displayed grapWcs pixd^ 

, . ^ , ^ , . S. The pipelined graphics controller of claim 7 further 

a pixel mux for selecting graphics pixels or movie pixels \ . i^"" ^ 

for display on a screen; . , ^ ""^r^te^counter for the CRT FIFO, the write counter 

a CRT FIFO, for receiving fetches of graphics pixels from ^ indicating a location within the CRT FIFO to write 

a graphics memory, the CRT FIFO supplying graphics graphics pixels fetched from the graphics memory, the 

pixels to the pixel mux; counter inaemcnted for true fetches and fcff 

a pixel counter for counting a number of pixels processed dummy fctdies. 

for display on the screen in a current horizontal line, the whereby the write counter is also incremented for dummy 

pixel counter outputting a current pixel count; fetches when no graphics pixels arc written into the CRT 

pixel coir^are means, receiving the current pixel count FIFO. 

and a starting pixel address and an ending pixel address 9. The pipeli ned graphics coptroller of claim 8 further 

of the movie window on the screen, for signaling to the compnsmg! 

pixel mux when to select movie pixels and when to a read counter for the CRT FIFO, the read counter 

select graphics pixels for display on the screen; go indicating a location within the CRT FIFO to read 

a fetch counter for counting a number of fetches of graphics pixels for transfer to the pixel mux. the read 

gr^>hics pixels from the graphics memory to the CRT counter continuously incremcoted by read requests 

FIFO, the fetch countCT counting true fetches wherein during a current horizontal line including when the 

valid graphics pixels are physically written to the CRT movie pixels arf srJr^d by the pixel mux. 

FIFO and counting dummy fetches wherein no valid 65 whereby ^^c&d counter is also incremented for nop- 

gr^hics pixcb are physically written to the CRT FIFO. displaying graphics pixels fcat ye_^replaced b y the movi e 

the fetch counter ou^utting a current fetch count; pixels by the pixel mux for oi^lay to the sctccp. 
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1#. The pipeUned graphics coatroUer of claim 1 further 
comprisiog: 

line fetch compare means. Fccdving the cuxrcnt fctdi 
count and recdviDg a Line fetch count the line fetch 
count being a total numba of fetches from graphics ^ 
memory to fetch all pixels in a horizontal Line without 
a movie window, for signaling an cad to fetching pixels 
for a current horizontal line when a match is detected. 

11. The pipelined grtqihics controller of claim 10 wherein 
fetches for the current horizontal line from the graphics i° 
memory to the CRT FIFO cease after the line fetch compare 
means signals the end to fetching pixels for the current 
horizontal line. 

12. The pipelined graphics controller of claim 4 further 
comprising: 

line fetch compare means, receiving the current fetch 
count and receiving a Line fetch count, the line fetch 
cotmt being a total number of fetches from graphics 
memory to fetch all pixels in a horizontal line without 
a movie window, for signaling an end to fetching pixels ^ 
for a current horizontal line when a match is detected. 

13. The pipelined graphics controller of daim 12 wherein 
the first fetch comparie means and the line fetch compare 
means include faring means for sharing a same con^arator. 

14. The pipelined graphics controller of claim 15 wherein ^ 
the sharing means for sharing the same comparator com- 
prises nuiUiplexoars and select logic to select either the 
starting pixel address of the movie window converted to 
fetches, or the line fetch count, to con:Q)arc to the current 
fetch count by the same comparator. ^ 

15. A method of overlaying a fiiU-motion-video envcl<^ 
onto a graphics display comprising repeating the following 
steps for a current horizontal line for ail lines in the graphics 
display: 

for a current horizontal line. coiiq>aring a top Line number 
and a bottom line number for top and a bottom bound- 
ary of the fuH-motioD-video envelope to a current line 
numl>er of the current horizontal line 

(a) when the current line number is not between the top 40 
Line numbicr and the bottom line number: 

fetctiing graphics pixels from a grai^cs memofy to a 
CRT FIFO; 

inaementing a current fetch count for each fetch of 
graphics pixels from the graphics memory; 43 

comparing the current fetdi count to a total fetch count 
for a hcnzontal line, the total fetch count being a 
total numt)er of fetches from the graphics memory to 
fetch all graphics pixels for the current h«izontal 
line; 50 

signaling an end of fetching for the cuirent horizontal 
line and stopping fetching from the graphics memory 
for graphics pixels in the cuirent horizontal line 
when the current fetch count matches the total fetch 
count; 55 

transfcxring fetched graphics pixels to a display screen; 

(b) when the current line number is between the top line 
number and the bottom line number, then the current 
horizontal line is comprised of a fb-st graphics region 
followed by a movie region followed by a second 60 
graphics region: 

fetching graphics pixels from the graphics memory to 

the CRT FIFO; 
incrementing the current fetch count for each fetch of 

graphics pixels from the graphics memory; 65 
con^aring die cuirent fetch count to a first fetch count 

for the first graphics region of the horizontal line, die 
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first fetch count being a total number of fetches from 
the graphics memory to fetch all graphics pixels for 
the first graphics region of the current horizontal 
line; 

signaling the start of dummy fetches, whereby dununy 
fetches to the CRT FIFO are performed when no 
graphics pixels are physically fetched from the 
graphics memory to the CRT FIFO, when the current 
fetch count matches the first fetch count; 

transferring the fetched graphics pixels for the first 
gr£9)hics region to the display screen; 

fetching movie pixels to a movie FIFO; 

transferring the fetched movie pixels for the movie 
region to the display screen; 

incrementing the current fetch count during dummy 
fetches when movie pixels are fetched to the movie 
FIFO; 

comparing the current fetch count to a second fetch 
count, the second fetch count being a sum of a width 
of the first gr^hics region and a width of the movie 
region of the current horizontal tine converted to 
fetches; 

signaling the end of movie fetches and stopping movie 
fetches for the cuirent horizontal Une and signaling 
the end of dummy fetches when the current fetch 
count matches the second fetch count; 

performing dununy fetches from the graphics memory 
to the CRT FIFO after die start of dununy fetches is 
signaled and before the end of dummy fetches is 
signaled; 

fetching graptiics pixels from the graphics memory to 
a CRT FIFO after the end of dummy fetches is 
signaled; 

incrementing the current fetch count for each fetch of 
graphics pixels from the graphics memory after the 
end of dummy fetdies is signaled; 

con^)aring the current fetch count to the total fetch 
count for the horizontal line, the total fetch count 
being a total number of fetches .from the graphics 
memcffy to fetch all graphics pixels for the cuirent 
horizontal line; 

signaling an end of fetching for the current horizontal 
line and stopping fetching from the gr^^hics memory 
for grai^cs pixels in the cuirent horizontal line 
when the current fetch count matches the total fetch 
count; 

transferring the fetched graphics pixels for the second 
graphics region to the display saeeiu 
whereby full-motion video is overlaid on the graphics dis- 
play but me fetching for the CRT FIFO continues using 
dummy fetches during the movie region. 

16. The method of claim 15 further conqirising die steps 

of: 

arbitrating for access to the graphics memory when a 
requestor requests access to the graphics memory, the 
requester being a host processor updating or reading the 
graphics pixels in the gr^hics memory or the requestor 
being for the fetching of movie pixels to the movie 
FIFO; and 

granting access to the requester and not to the CRT FIFO 
for a simultaneous screen-refresh request from the CRT 
FIFO after the start of dummy fetches is signaled and 
before the end of dummy fetches is signaled but 
granting access to the CRT FIFO when dummy fetches 
is not signaled, 
whereby requesters win arbitration during dummy fetches. 

17. The method of claim 16 wherein transfer of graphics 
pixels to the ffaphics screen occurs in parallel to fetching of 
graphics pixels, but staggered by a pipeline deLay. 
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18 A graphics controller comprising: an arbiter, coupled to a requester, for arbitrating access to 

a pixel mux for sdccting eitto graphics pixels or movie ^ memory fl.e artito^^higher pri- 

Vbtels for display to a screen: only to Ae requests than to the 

^ ^ ^ ...... dummy fetch mdicatar is activated. 

a pUcl con^jaratcff for companng a honzontal address of ^ ^^licrcby the CRT FIFO continues to advance during movie 

a current pixel to a starting and an ending pixel address fetches but allows the host processor to access the grairtucs 

of a movie window, the pixel mux selecting the movie memory using a dummy fetch that also advances the CRT 

pixels for display when the hcrizontal address of the FIFO. 

current pixel is between the starting and the ending 19. The grq)hics controller cf claim 18 wherein the 

pixel address; requestor is the host processor or a movie request 

a CRT FIFO for buffering graphics pixels from a graphics ^ 20. The graphics controller of claim 18 wherein the CRT 

mcmoiy to the pixel mux: requests fetches from the graphics memory during 

f ' ^ ^ displayofmoviepixelsas well as during display of graphics 

a frtdi comparator for comparmg (a) a ci^^^J^^ pUelsf the dummy fetches occumng when the m^^^^ 

address to a staitmg movie fetch address, the stotrng ^^^^ ^^^^^ 

movie fetch address being the starting pixel address 15 ^1. The gr^hics controUcr of daim 20 further compris- 

divided by a number of pixels fetched from the graph- -j^g. 

ics memory for cadi fetch cycle, the fetch comparator ^ j^^^ coupled to receive gr^cs pixels and movie 

also for comparing (b) the current fetch address to an p^^^ convcrting the movie 

ending fetch address for a horizontal line, the ending ^^^^^^ graphics pixels to analog voltages for 

fetch address being an address of the last graphics pixel 30 o\itput to die so-ecn. 

at the edge of the screen, the fetch con^arator also for 22. The graphics controller of claim 21 further compris- 

con^jaring (c) the current fetch address to a final movie [jxg: 

fetch address, the final movie feldi address being the ^ half-frame buffer for buffering pixels for half of the 

ending address of the movie window divided by the screen, the half-frame buffer coupled to half of a 

number of pixels fetdied from the graphics memory for 33 flat-panel screen. 

each fetch cycle; . 23. The gr^hlcs controller of daim 21 further compris- 

a dummy fetch indicator, being activated by die fetch Ing: 

con^arator when the current feAch address matches the a fuU-frame buffer for buffering pixels for the screen* the 

starting movie fetch address, the dummy fetch indicator full-frame buffer coupled to a flat-pand screen, 

being de-activatcd when the current fetch address 30 24. The gr^hics concroller of daim 21 further compris- 

matches the final movie fetch address; ing: 

a dummy fetch generator, responsive to the dummy fetch a gray-scale controller, coupled to rccdve pixels from the 
indicator, for generating a dummy fetch, the dummy pixel mux. for convcrting pixels to a format used by a 
fetch being a fetch wherein no graphics pixels which flat-panel display screen, the gray-scale controller out- 
are displayed are physically written to the CRT FIFO, 3^ putting converted pixels to the flat-panel display 
but the current fetch address is advanced without die saeen. 
CRT FIFO receiving graphics pixels in the dummy 

fetch; and ***** 
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